第三週開始是系統開發，
首先我們要先瞭解系統的全貌，從 wireframe 下手。

--------系列簡介--------

網站系統可說是現在最多學子與新人想要入門的一個領域，
這個原本屬於新興的領域，這幾年來也累積許多年的知識與 pattern ，
在有限的環境（stateless）與有限的伺服器端、瀏覽器資源下，
成為許多人進入程式的一塊入門鐵板(?)。

這個系列希望能夠就網站系統設計幾個門檻著手，
這是設定給初心者作為學習，給同好們作為回顧，

重新認識有關網站系統的每個環節。
第三週開始，我們要慢慢進入正式的系統開發了，
在我們正式進入開發之前，我們得知道我們要開發些什麼。

所以在這一篇文章中，
我將會身兼需求與設計者，透過自問自答的方式建構需求。

＠ 網站系統？到底要作什麼？

從筆者曾從事數年的接案經驗與工作經驗中，
大多數發案方或主管找接案者，大概不脫幾種情境：

1.希望模仿別人網站上的功能，但是加上自己的外觀，
並由自己管理內容、提供自己所知道的 domain knowhow ，
以同樣的系統創造出不同的內容作為區隔。

2.現在有紙本作業或人力作業的現況，
希望透過資訊化來達成更有效率的作業以及更能作為餐考得統計資料。

某個角度上而言，可以說都是重現某些操作在資訊系統上，
但是我們會發現資訊系統是資訊系統，其他操作是其他操作。

每個系統需要的流程跟介面都不太一樣，
有哪些內容跟操作也是會大致上很像，但是細節卻是有很多不同。

這時候在開始時，如何去設定一個範圍跟一個需求，就變得很困難。

以下我們可以大概試著走一次簡易板的需求訪談流程。
（我們第八天時練習過，還記得嗎？:p）

業主：
「我希望建立一個網站可以讓使用者可以發文跟註冊，
使用者留言要可以看、可以分類。」

一般有幾種分析需求的方式：

@ SiteMap

SiteMap 這個詞主要是以前常用的一種介紹的 pattern，

會有一個頁面詳列網站的所有功能與操作，像網站導覽頁或是多層的選單。
所以 SiteMap 也就被被認為是網站的功能清單。

但近年來由於搜尋引擎的發達跟資料內容操作的不斷增加，
現在連選單都很少有完整得操作，試想像 facebook 這麼複雜的網站，
要清楚條列其中的功能幾乎是不可能的，所以幾乎都是分層結構，
每一層決定部份功能，用層層套疊的方式設計。

另外提到 SiteMap ，搜尋引擎也有關的參考，
搜尋引擎希望網站列舉出所有頁面的一個紀錄檔，就稱為 sitemap.xml。
使用者可以在其中條列出所有頁面方便 search engine 去進行擷取。

所以 SiteMap 這個詞就是這麼樣一個詞。

總之以 SiteMap 模型進行的作法，會是由網站核心與描述去推導功能，
像是這樣

* 會員系統
** 註冊
** 登入
* 文章系統
** 發文
** 瀏覽分類
** 瀏覽文章

優點是單元清楚，但缺點是不易描述執行細節，
有點像是文章的大綱，但是無法決定文章的細節。

＠ User Story

另一種作法是建立最少必須的 Use Case，
把使用者能進行的所有操作一一列舉。

如剛剛
「我希望建立一個網站可以讓使用者可以發文跟註冊，使用者留言要可以看、可以分類。」
從這句話中，可以再細分為

A.使用者發文 Use Case
1.使用者可以透過操作介面發表文章。

B.會員註冊 Use Case
1.使用者填寫資料註冊

C.閱讀留言 Use Case
1.使用者連上頁面後可以看見留言

D.留言分類 Use Case
1.使用者可以瀏覽分類裡面的所有留言

這些分析方法是在口語化的對談中摘錄紀錄，
與觀察別系統的結果，化為一項一項的代辦事項。

最終的目標是化成雙方能有共識的系統開發合約與細節，
作為系統開發與需求端兩者的協議。

以此避免做出與雙方想像中有落差的系統。

當然你會發現不管是 Sitemap 也好或是 User Story 也好，
他們都只是將問題系統化的一種方法，並沒有所謂優劣。

就使用者真正想要得東西，
就上面第一層最概略的需求分析，都還無法真正接觸到細節，

這是因為需求分析本來就是一個反覆逼進的過程。

一般而言，就系統分析的狀況下，

系統分析師常會認為需求端不知道他們需要什麼，這乍聽之下有點弔詭，
因為要做什麼是從他們分析出來的，但筆者認為這是有道理的。

是因為對需求端而言，他們只重視結果而非過程，
他們希望出現一個這樣又那樣的系統，但是那些結果受限於經驗與想像。

但是對系統開發而言，他是理所當然包含著過程的，

像是舉個例子，以文章發表系統而言，
使用者希望的是可以簡單的發表出圖文華麗的系統，

但是怎麼樣是簡單，使用者往往並不知道。

他們心中所想的是結果（圖文華麗的文章），
怎麼去發表圖文華麗的文章，他們相對而言不是那麼重視。

有些人認為採用 word 直接上傳呈現結果是簡單，
有人認為採用 wiki 或 markdown 語法是簡單，
有人認為 WYSIWYG 圖文編輯器是簡單，

但是追根究底，隨著不同需求而言，
他們不見得真的這麼重視或瞭解這個細節。

所以他們有可能只是參考別人的系統，選擇一個功能，
最後卻發現他們的需求其實用另一個作法更符合他們需要，
只是他們不曾用過。

但對系統開發而言，我們需要面對每一個會呈現給使用者的頁面，
每一個細節我們都可能會接受到使用者的意見與反饋，所以相對而言，

系統分析師應該要比需求端更理解跟能分析出不同需求真正的細節。

而需求端則應該清楚他們希望有什麼樣的結果，
並確保這個意見有傳達給系統分析師，讓系統分析師瞭解。

雙方應該針對不同的目標與內容，盡到不同的本分，
系統分析師應該以實作經驗說明細節與開發負擔、成本，
而需求端應該將目標定義明確。

最忌諱是雙方都態度強硬的試著去指導或領導對方。

就筆者經歷過事後驗證為好設計的狀況，是以系統分析師為多，
因為系統分析師通常經歷過許多專案，同樣類型的 UI 與功能，

可能已經實作過無數次，能明白很多想法和實際上的落差。

而使用者容易落入空想，而無法瞭解這些自認「好點子」背後的實作問題。

當然經驗也有別，需求端不太容易一直在參與開發新系統，
通常都是因為需求發生才需要，但系統分析師會一直在不同專案中，

持續進行不同的需求分析，兩者的經驗當然是有別的。

系統設計者的職責是從這些意見中，聽取使用者的意見，
並且從自己的系統開發經驗中，擷取那些已經成熟的系統部份，

將過去所經歷、開發過的相似專案優點與問題，
重新思考後加以混和使用者的需求，

從中做出一個既符合使用者需求，又能夠相對理想的系統。

承前述所以就筆者的看法而言，
系統分析師本身是需要有開發經驗與實務經驗相輔相成的。

否則即使能夠規劃出系統，但卻無法正確估算各個實作細節與難度，
得再倚賴賴其他角色進行協助規劃與再分析。

當然系統分析本身也需要有能夠化情境為系統的分析功力，
亦非資深開發工程師便能轉職成系統分析。

有些扯遠了，回頭繼續聊原本的主題，網站功能分析（wireframe） ，

基本上就是從虛無中分析出一系列的需求，
並且試著去滿足這些不明確而且隨時可能會互相影響、變動的需求。

世界上沒有不變的需求，只可能有不變的時程。 （笑）

就 Wireframe 的工具，一般而言會是混用 sitemap 法跟 user story 法。

理由很簡單，計算功能模組跟架構切分時，我們需要能計算功能的單位，
以利估價（在公司的話，就是估時程）與切分時程。

User Story 在估時程上比較不容易，
是因為不同 user story 之間可能有重疊部份，時程很難估算。

即使我們一一將不同 user story 的時程估算出來，
也不一定能代表總時程。（相依性等）

但是 sitemap 無法描述每個細節，所以針對一些比較重要的重點部份，
我們仍然會採用 user story 法進行細節的描述，
盡可能增加工程師對這個功能的認知。

分析後的需求書有點像是樹的種子，可以從種子外觀看出可能是什麼樹，
但是在他真正長大成樹之前，你很難知道他到底會長多高多大。

需求分析的重點一方面是定義需求，
但另一方面真正重要的事情筆者認為是避免事後的爭議。

失敗的專案中，往往有相當高的比例來自於驗收方與開發方的認知不同。

比起毫無憑據的相互誤會與責難，
事先雙方有一份共識的規格作為憑據，會比較容易解決這種困境。

（當然，如果有一方就是不願意合作，再好的規格書都無法幫助雙方溝通。
合約上文字是死的，但是人的解釋是活的。）

另外就網站而言，因為功能離真正的畫面還有段距離，

即使一個網站將所有功能都確實實作完了，
也可能因為 UI 使用者認為不好看、資訊不足，
沒有正確依照重要性呈現內容，而可能產生誤會。
（即使功能上完全滿足）

這時候我們除了文字描述功能以外，
可能還會佐以所謂方塊圖進行討論。

這篇基本上文字與需求分析的申論已經太多了，
我們直接切入我們接下來要作為示範用專案的需求分析吧。XD

ps. 因為這是自問自答，所以請不要奇怪，
這個發案方怎麼會這麼有 sense，這在現實中是可遇不可求的事情。

＠ 假設有以下對話

發案方：
「我希望我們有一個會員系統，用來紀錄有興趣參與我們活動的會員，
並且這些會員可以發表一些與活動主題文章。」

「我希望這些文章可以為這個網站跟作者帶來許多的使用者，
但是考慮到文章可能會很多加上瀏覽者可能不會每篇都有興趣，
所以我希望在上面加上分類，讓使用者可以簡單找到他們有興趣的文章。」

「如果作到這樣的話，我們就可以透過這個活動主題，
讓我們公司更有知名度，也更容易去談商業合作，
所以我需要這樣一個系統。」

分析方：
「好的，首先我先分析一下，您需要一個會員系統，
所以我們會有會員註冊與會員註冊的部份。
不曉得您希望其中會員註冊的部份需要什麼內容呢？

我認為您至少需要一個帳號跟密碼，還有 email 作為聯絡用，
為了方便起見，也可以使用 email 作為帳號再加上一組密碼。」

「另外您提到會有文章發表系統，所以我們會有一個表單，
能讓登入後的使用者進行發文的動作，因為您提到發文的動作，
所以從過去經驗，我會認為您可能會有編輯跟刪除的需求。」

「另外您提到分類的部份，加上文章這個部份是比較相依於作者，
所以我認為您的分類主要是針對同一作者的文章進行分類。」

「您提到希望使用者可以簡單找到他們有興趣的文章跟帶來更多使用者，
現在使用者大多會透過搜尋引擎[/b[以及[b]社群網站分享來瀏覽網路，
所以我想您可能對於這兩個部份的細節也會有相關興趣。」

發案方：
「有關會員資料大致上無誤，除了 email 及密碼 以外，
我希望能夠使用者能夠填寫的性別跟生日，
因為這樣我可以更瞭解我的目標族群並在下一階段為其做更多規劃。」

「文章發表系統的部份，希望使用者可以有機會做簡易的排版，
並且能夠加入圖片，這樣文章效果才會比較好。
另外文章的確需要修改與刪除沒錯，
並且如果使用者發表不適當（如違法）的文章，
我希望我能有一個管理介面可以直接刪除該篇文章。」

「分類的部份除了需要對單一作者文章的分類而言，
我也希望能夠有一個全站的文章分類，方便使用者認識更多作者。」

「有關搜尋引擎的部份，希望使用者搜尋對應類別名稱時或特定標題時，
能夠更有機會搜尋到我們網站。」

「有關 Facebook 社群的部份，我不太瞭解細節，你有什麼建議嗎？」

接案方：

「有關會員資料的部份，好的，瞭解了。
另外我想您可能會需要 email 驗證，以免使用者填寫錯誤 email ？」

「有關文章系統的部份，這邊流程比較複雜，我已經概略瞭解您的需求，
我們之後將再進行具體的流程設計再與您約時間詳細討論這個部份。

包括文章需要哪些細節等，請您將您希望文章有的欄位，
跟大概的資訊做個整理，我們再下次會議時可以再針對這部份討論。」

「分類的部份這樣我明白了，我們會以此先去進行規劃。」

「搜尋引擎的部份我們能夠做的事情是給予理想的網站標題與描述，
以利搜尋引擎索引瞭解我們網站，這部份可以再討論什麼樣的網站標題，
是屬於我們需要的部份。」

「有關 Facebook 社群，建議是文章可以採用按讚(like)這推薦系統，
讓使用者能夠對這個文章本身進行推薦，以此達到社群擴散的效果。

或是提供分享按鈕讓有意願的使用者進行分享，
當然前提得是這些內容有這個價值讓使用者去作這些事情。」

發案方：

「對， email 驗證的部份是需要的。另外使用者可能會忘記密碼，
這個部份也需要提供一個方式讓他們取回密碼。」

「好的，發文系統是這系統的重點，我們可以再另約時間討論。」

「網站標題的部份我會再想想，下次需求會議時再討論。」

「我認為按讚是一個很好的點子，我們也可以瞭解瀏覽者的感覺，
那就這麼做。至於分享，在文章品質不明確的情況下，
可能不會有太多人用，這不是目前最急迫的事情，可以先不列入。」

接案方：
「好的，我瞭解了。我先回去分析細節，我們下次需求會議再談。」

筆者認為好得需求訪談，應該是在彼此對需求都慢慢瞭解，
並且提供彼此知道的知識，互相接力的邁向最後一個系統模型。

並且協助對方濾掉不必要的負擔，獲得自己真正需要的東西。

好的合作是雙方各提其專業，若單方面的由其中一方主導，
並不是一件好事，得相輔相成。

從這樣的對話中，如果是您，您會怎麼寫需求分析書(wireframe)呢？

又，筆者會怎麼寫這份對話的需求分析書呢？

這個問題的答案，我們就留待明天再進行討論囉。（笑）

明天見。 ;)